The present application relates to digital data processing, and more particularly to garbage collection for shared data entities.
FIG. 1 illustrates a client/server system 50 in which a network 75 links a server 80 to client systems 62, 64, 66. The server 80 is a programmable data processing system suitable for implementing apparatus, programs, or methods in accordance with the invention. The server 80 provides a core operating environment for one or more runtime systems that process user requests. The server 80 includes a processor 85 and a memory 90. The memory 90 can be used to store an operating system, a Transmission Control Protocol/Internet Protocol (TCP/IP) stack for communicating over the network 75, and machine-executable instructions executed by the processor 85. In some implementations, the server 80 can include multiple processors, each of which can be used to execute machine-executable instructions. The memory 90 can include a shared memory area 92 (shown in subsequent figures) that is accessible by multiple operating system processes executing in the server 90. An example of a suitable server that can be used in the client/server system 50 is a Java 2 Platform, Enterprise Edition (J2EE) compatible server, such as the Web Application Server developed by SAP AG of Walldorf (Baden), Germany (SAP), or the WebSphere Application Server developed by IBM Corp. of Armonk, N.Y.
Client systems 62, 64, 66 can execute multiple applications or application interfaces. Each instance of an application or an application interface can constitute a user session. Each user session can generate one or more requests to be processed by the server 80. The requests can include instructions or code to be executed on a runtime system (e.g., the virtual machine 100) on the server 80.
A runtime system is a code execution environment that executes instructions or code in user requests and that provides runtime services for that code. Core runtime services can include functionality such as process, thread, and memory management (e.g., laying out objects in the server memory 90, sharing objects, managing references to objects, and garbage collecting objects). Enhanced runtime services can include functionality such as error handling and establishing security and connectivity.
One example of a runtime system is a virtual machine. A virtual machine (VM) is an abstract machine that can include an instruction set, a set of registers, a stack, a heap, and a method area, like a real machine or processor. A VM essentially acts as an interface between program code and the actual processor or hardware platform on which the program code is to be executed. The program code includes instructions from the VM instruction set that manipulates the resources of the VM. The VM executes instructions on the processor or hardware platform on which the VM is running, and manipulates the resources of that processor or hardware platform, so as to effect the instructions of the program code. In this way, the same program code can be executed on multiple processors or hardware platforms without having to be rewritten or re-compiled for each processor or hardware platform. Instead, a VM is implemented for each processor or hardware platform, and the same program code can be executed in each VM. The implementation of a VM can be in code that is recognized by the processor or hardware platform. Alternatively, the implementation of a VM can be in code that is built directly into a processor.
As an example, a Java source program can be compiled into program code known as bytecode. Bytecode can be executed on a Java VM running on any processor or platform. The Java VM can either interpret the bytecode one instruction at a time, or the bytecode can be further compiled for the real processor or platform using a just-in-time (JIT) compiler.
In addition to Java VMs, other examples of VMs include Advanced Business Application Programming language (ABAP) VMs and Common Language Runtime (CLR) VMs. ABAP is a programming language for developing applications for the SAP R/3 system, a widely installed business application system developed by SAP. The Common Language Runtime is a managed code execution environment developed by Microsoft Corp. of Redmond, Wash. For purposes of simplicity, the discussion in this specification focuses on virtual machines, but it is to be understood that the techniques described herein can also be used with other types of runtime systems.
When executing, runtime systems create and reference local data entities. Many different types of local entities can be created, including, for example, strings, constants, and variables, objects that are instances of a class, runtime representations of a class, and class loaders that are used to load class runtime representations.
When a local entity is no longer being used by a runtime system, the memory being used to store the local entity needs to be reclaimed—i.e., freed or otherwise released and returned to the pool of available memory—so that it can be used to store new data entities. In some environments, programmers must explicitly reclaim the memory they have allocated for local entities (e.g., by explicitly calling functions to free specified sections of memory). In other environments, the reclamation of memory is handled through a technique known as garbage collection.
Garbage collection is a process designed to identify and reclaim blocks of memory that have been dispensed by a memory allocator but that are no longer “live” (i.e., no longer being used, as determined, for example, by not being reachable from any currently referenced objects or entities). Garbage collection can sometimes be handled as a background task by runtime systems rather than as an explicit task by user programs. Garbage collection can also be handled as an inlined task.
Systems that reclaim memory through garbage collection provide several advantages over systems that leave reclamation up to users—in particular, systems that use garbage collection tend to be more reliable, as they help to eliminate common programming problems such as dangling pointers and memory leaks. There are some costs associated with garbage collection, however, as access to memory must typically be restricted and runtime systems must sometimes be halted, at least during some portion of the garbage collection process. Nevertheless, garbage collection is frequently used to reclaim memory in runtime systems, and there are many known garbage collection algorithms (e.g., reference counting, mark-sweep, mark-compact, and copying algorithms).
Multiple runtime systems can be executed in parallel in order to increase the performance and scalability of server environments. When multiple runtime systems are executed in parallel, resource (e.g., memory) and time consumption can be reduced by sharing entities between the runtime systems. There are multiple known techniques that can be used to share entities, and many different types of entities can be shared (including for example strings, constants, variables, object instances, class runtime representations, and class loaders).
The lifetime of shared entities may be different than the lifetime of local entities, and as such, it may not be possible to use standard garbage collection techniques to reclaim memory that is being used to store shared entities. For example, it may not be possible to use a local garbage collection process for garbage collection of shared entities. A local garbage collection process, which is normally used to reclaim local memory (e.g., memory being used to store local entities associated with one runtime system), is typically designed to garbage collect a data entity when that runtime system no longer references the data entity. However, a shared entity should not necessarily be garbage collected when one runtime system no longer references the shared entity, as other runtime systems may still be referencing the shared entity. Garbage collection of shared entities thus requires some coordination and cooperation between participating runtime systems.